home *** CD-ROM | disk | FTP | other *** search
/ Internet Surfer: Getting Started / Internet Surfer - Getting Started (Wayzata Technology)(7231)(1995).bin / pc / textfile / mac_faqs / smalltal < prev    next >
Internet Message Format  |  1995-01-30  |  32KB
  1. Xref: bloom-picayune.mit.edu comp.lang.smalltalk:5815 news.answers:4329
  2. Path: bloom-picayune.mit.edu!enterpoop.mit.edu!spool.mu.edu!agate!con.Berkeley.EDU!latta
  3. From: latta@xcf.berkeley.edu (Craig R. Latta)
  4. Newsgroups: comp.lang.smalltalk,news.answers
  5. Subject: Smalltalk Frequently-Asked Questions (FAQ)
  6. Supersedes: <smalltalk-faq_720768652@xcf.berkeley.edu>
  7. Followup-To: poster
  8. Date: 1 Dec 1992 12:44:31 GMT
  9. Organization: University of California, Berkeley
  10. Lines: 847
  11. Approved: news-answers-request@MIT.Edu
  12. Distribution: world
  13. Expires: 25 Dec 1992 12:45:14 GMT
  14. Message-ID: <smalltalk-faq_723213914@xcf.berkeley.edu>
  15. Reply-To: smalltalk@xcf.berkeley.edu
  16. NNTP-Posting-Host: con.berkeley.edu
  17. Summary: This posting contains a list of frequently-asked questions
  18.         (and their answers) about the Smalltalk programming
  19.         language and environment. It should be read by posters
  20.         to comp.lang.smalltalk.
  21. Originator: latta@con.Berkeley.EDU
  22.  
  23. Archive-name: smalltalk-faq
  24. Last-modified: 1992/12/1
  25. Version: 3.0
  26.  
  27.  
  28. ***
  29.  
  30.     This is a Smalltalk frequently-asked-questions (FAQ) sheet,
  31. distributed by Craig Latta (latta@xcf.Berkeley.EDU). It is posted
  32. fortnightly to the USENET newsgroups comp.lang.smalltalk and
  33. news.answers.
  34.     It is also available via ftp as
  35. anonymous@xcf:misc/smalltalk/FAQ/FAQ.entire. Finally, it can be
  36. obtained by mail by emailing smalltalk-request@xcf with the subject
  37. line "request for FAQ". The machine xcf.Berkeley.EDU has IP address
  38. 128.32.138.1.
  39.  
  40.         Please send contributions, suggestions and comments to
  41. smalltalk-request@xcf.Berkeley.EDU. Raw FAQ submissions (which I have
  42. not yet incorporated into this document) are available (in 'mh'
  43. message format) via 'ftp' as
  44. anonymous@xcf.berkeley.edu:misc/smalltalk/FAQ/raw/*.
  45.     Comments and suggestions are greatly appreciated. I realize
  46. that information has a short half-life.
  47.  
  48.     Disclaimer: I am an employee of ParcPlace Systems, Inc., but I
  49. am solely responsible for this FAQ and its contents. In August 1992, I
  50. solicited comments about the appropriateness of my maintaining and
  51. posting this FAQ. The feedback I got was unanimously approving.
  52.  
  53.  
  54.         Thanks,
  55.  
  56. -C
  57.  
  58.  
  59.     New items are marked with a '+'. Modified existing items are
  60. marked with a '*'.
  61.  
  62.     Contents:
  63.  
  64. 0.0)    [Meta-issues]    
  65. 0.1)        How can I browse ftp sites and their data without
  66.             using my own disk space (unless I want to keep
  67.             data), and locate files on ftp sites, given
  68.             pathname fragments?
  69.  
  70. 1.0)     [Archival]
  71. 1.1)        How can I get GNU Smalltalk?
  72. 1.2)        What Smalltalk archives are there?
  73.  
  74. 2.0)     [Projects]
  75. 2.1)        What is Smallmusic?
  76.  
  77. 3.0)     [References]
  78. 3.1)        Can someone recommend a good introduction to
  79.             Model-View-Controller concepts?
  80. 3.2)        Is there a Smalltalk bibliography?
  81. 3.3)+        What are the "blue book", "purple book", etc?
  82.  
  83. 4.0)+    [Programming issues]
  84. 4.1)+        What are some "classic Smalltalk bugs", both in the
  85.             system and programmer domains?
  86.  
  87. ---
  88.  
  89. 0.0) [Meta-issues]    
  90.  
  91. ---
  92.  
  93. 0.1)        How can I browse ftp sites and their data without
  94.             using my own disk space (unless I want to keep
  95.             data), and locate files on ftp sites, given
  96.             pathname fragments?
  97.  
  98. Answer:
  99.  
  100.     This question might seem tangential at first (and I suppose it
  101. is). But it is vitally important, as resources such as papers,
  102. documentation, code and software tools become more numerous and
  103. distributed.
  104.  
  105.         There is a set of Emacs-Lisp ("elisp") code, called
  106. "ange-ftp.el", which makes 'ftp' use transparent within GNU Emacs (GNU
  107. Emacs is available via anonymous ftp from prep.ai.mit.edu). This
  108. package attempts to make accessing files and directories using FTP
  109. from within GNU Emacs as simple and transparent as possible.  A subset
  110. of the common file-handling routines are extended to interact with
  111. FTP. Using these routines, one is able to access remote files and one
  112. would any other local file, without having to write it locally to
  113. disk. The result is an immense virtual global filesystem.
  114.         The routines are available via anonymous ftp (naturally!) as
  115. tut.cis.ohio-state.edu:/gnu/emacs/elisp-archive/as-is/ange-ftp.el.Z,
  116. (incidentally, if you already had "ange-ftp.el", you could paste the
  117. above line in response to Emacs' 'copy-file', stick "/anonyous@" in
  118. front of it, and copy the file.) My current version is dated 22
  119. October 1991.
  120.         Another useful bit of elisp is "saveconf.el". It saves the
  121. Emacs buffer list and window configuration between editing sessions.
  122. So, one can have several buffers, with several files open (as I
  123. usually do), quit and restart Emacs, and have the state preserved,
  124. cursor locations and windows included. Happily, it works well with
  125. "ange-ftp.el", so that even remote files are restored (after possibly
  126. having to prompt for passwords). "context.el" is also available via
  127. anonymous ftp from cis.ohio-state.edu, as
  128. pub/gnu/emacs/elisp-archive/saveconf.el.Z. Also look for
  129. "tree-dired.el" which provides for hierarchical directory editing.
  130.         Incidentally, it was very easy to produce references for the
  131. above tools, thanks to another tool called "archie", developed at
  132. McGill University. Dubbed a "resource discovery tool" by its authors,
  133. it comes in very handy when one knows what tools are needed but not
  134. their availability. Archie consists of a server for this information
  135. (basically from a database of directory trees from "all known"
  136. anonymous ftp sites, updated once per month), and a client, which may
  137. be run via 'telnet' from the server machine itself (frowned upon...),
  138. or from a standalone client available from that machine (...highly
  139. encouraged, for the considerable host load win). Some clients even
  140. perform ftp tasks based on user response to search results. There are
  141. clients available for dumb and X terminals as well as for (of course)
  142. Emacs. Poke around archie.mcgill.ca for a client and documentation.
  143.  
  144.     Porting these tools (or at least new interfaces to them) to
  145. Smalltalk would be a great project. I'm working on it in my spare
  146. time. I'd love to hear from any interested people.
  147.  
  148.  
  149. -Craig
  150.  
  151.  
  152. ---
  153.  
  154. 1.0)     [Archival]
  155.  
  156. ---
  157.  
  158. 1.1)        How can I get GNU Smalltalk?
  159.  
  160. Answer:
  161.  
  162.     The most current location, to my knowledge, is
  163. anonymous@prep.ai.mit.edu:pub/gnu/smalltalk-1.1.1.tar.Z. Please direct
  164. problems to the author, Steven Byrne, at sbb@eng.sun.com.
  165.  
  166.  
  167. ---
  168.  
  169. 1.2)        What Smalltalk archives are there?
  170.  
  171. Answer:
  172.  
  173.     There are many. Most of them simply archive GNU smalltalk, but
  174. there are also a few large archives containing many interesting and
  175. varied sources. All of the sites may be retrieved by invoking 'archie
  176. smalltalk' (see above reference to 'archie'). 
  177.     For convenience, descriptions of a few of the archives follow.
  178. If you have a site/announcement you'd like included, please let me
  179. know.
  180.  
  181.  
  182. **
  183.  
  184. Directory: anonymous@xcf.berkeley.edu:misc/smalltalk
  185. Summary:
  186.     
  187.     Smalltalk FAQ, smallmusic discussion archive.
  188.  
  189. **
  190.  
  191. Host: mushroom.cs.man.ac.uk
  192. Summary: The Manchester Smalltalk archive. Information about it is
  193.     posted regularly to comp.lang.smalltalk.
  194.  
  195. **
  196.  
  197. File: anonymous@st.cs.uiuc.edu:pub/Index
  198. Summary: Information about the UIUC Smalltalk archive (which has local
  199.     files and a mirror of the Manchester archive).
  200.  
  201. **
  202.  
  203. File: anonymous@ccrma-ftp.stanford.edu:pub/st80/README
  204. Summary: Information about various Smalltalk-related offerings,
  205.     including the Musical Object Development Environment (MODE).
  206.  
  207.  
  208. ---
  209.  
  210. 2.0)     [Projects]
  211.  
  212. ---
  213.  
  214. 2.1)        What is Smallmusic?
  215.  
  216. Answer:
  217.  
  218.     A work group has formed to discuss and develop an
  219. object-oriented software system for music. The current environment is
  220. Smalltalk 80. The email address for the group is
  221. smallmusic@xcf.Berkeley.EDU.  If you are interested in joining the
  222. discussion, email smallmusic-request@xcf.Berkeley.EDU, with the
  223. subject line "add me".
  224.  
  225.     The abstract and outline to a recent version of our working
  226. paper follows. The document is available via ftp as
  227. anonymous@ccrma-ftp.stanford.edu:pub/st80/OOMR6.t.
  228.  
  229.  
  230.     Thanks,
  231.  
  232.     Craig Latta
  233.     latta@xcf.Berkeley.EDU
  234.  
  235. ***
  236.  
  237. Abstract to the working document
  238.  
  239.     This document describes an object-oriented description
  240. language for musical parameters, events and structures known as the
  241. Smallmusic Object Kernel (SmOKe) .  In object-oriented software terms,
  242. the representation is described in terms of software class hierarchies
  243. of objects that share state and behavior and implement the description
  244. language as their protocol. 
  245.     The authors believe this representation, and its proposed
  246. linear ASCII description in Smalltalk-80 syntax, to be well-suited as
  247. a basis for: (1) concrete description languages in other languages,
  248. (2) specially-designed binary storage and interchange formats, and (3)
  249. use within and between interactive multi-media, hypermedia
  250. applications in several application domains.
  251.  
  252.  
  253. ---
  254.  
  255. 3.0)     [References]
  256.  
  257. ---
  258.  
  259. 3.1)        Can someone recommend a good introduction to
  260.             Model-View-Controller concepts?
  261.  
  262. Answer:
  263.  
  264. From: ege@blitz.fiu.edu (Dr. Raimund K. Ege)
  265. Newsgroups: comp.lang.smalltalk
  266. Subject: Re: MVC -- good introductions?
  267. Date: 8 Mar 92 18:26:40 GMT
  268. Organization: Florida International Univ.
  269.  
  270. Look at Chapter 10 in the following book that just came out:
  271.  
  272. Programming in an Object-Oriented Environment,
  273. by Raimund K. Ege
  274.  
  275. Academic Press, Inc., San Diego, CA, 1992, hardcover,
  276. ISBN 0-12-232930-9
  277.  
  278. To order call 1-800-321-5068.
  279.  
  280. (also: Academic Press Limited, London, United Kingdom)
  281.  
  282. It presents a complete and thorough introduction to all object-oriented
  283. concepts. It contains a large
  284. example/case study, and a comparison of major OO programming languages. 
  285.  
  286. In addition, the book extends the object-oriented view
  287. to all elements of the programming environment: data structures
  288. and algorithms, programming tools, user interfaces, data bases and
  289. software design. 
  290.  
  291. Chapter 10 is on user interfaces: it describes and illustrates
  292. the Smalltalk MVC paradigm (also: InterViews)
  293.  
  294. -- 
  295. Raimund K. Ege                             School of Computer Science
  296.                                              Florida Int'l University
  297. ege@scs.fiu.edu           (305) 348-3381              University Park
  298. ege@servax.bitnet     FAX (305) 348-3549              Miami, FL 33199
  299.  
  300. **
  301.  
  302. From: asmundvn@dcs.glasgow.ac.uk (Nils Erik Asmundvaag)
  303. Newsgroups: comp.lang.smalltalk
  304. Subject: Re: MVC -- good introductions?
  305. Date: 11 Mar 92 10:56:38 GMT
  306. Organization: Glasgow University Computing Science Dept.
  307.  
  308. The book
  309.  
  310.     Smalltalk-80: A Practical Introduction
  311.     (ISBN 0-273-03105-8)
  312.  
  313.     by Philip D. Gray & Ramzan Mohamed, 1990
  314.     and published by Pitman (at least in the UK)
  315.  
  316. contains two chapters on interactive applications and the MVC.
  317.  
  318. I found it very helpful when first learning about the MVC.
  319.  
  320. Nils E. Asmundvaag
  321.  
  322. -- 
  323. -------------------------------------------------------------------------------
  324. Nils Erik Asmundvaag                         
  325. University of Glasgow, Scotland
  326. asmundvn@dcs.glasgow.ac.uk      asmundvn@uk.ac.glasgow.dcs
  327.  
  328.  
  329. **
  330.  
  331. From: bruce@utafll.uta.edu (Bruce Samuelson)
  332. Newsgroups: comp.lang.smalltalk
  333. Subject: Re: how are st80 views and controllers used?
  334. Date: 12 Mar 92 14:12:48 GMT
  335. Organization: UTexas at Arlington, Linguistics
  336.  
  337. There are two papers on MVC that provide an introductory overview of
  338. the pre-version 4.0 ST80 scheme.  Much of what's in them also applies
  339. to version 4.0.  I understand that one of PPS's priorities in the
  340. forthcoming version 4.1 will be improved documentation.  We'll see how
  341. well they explain the new windowing scheme launched in version 4.0.
  342. It would certainly be helpful to get an overview of what's going on
  343. before plunging into the source code of the myriad new classes.
  344.  
  345. (1) A Cookbook for using the Model-View-Controller User Interface
  346. Paradigm in Smalltalk-80 by Glenn E. Krasner and Stephen T. Pope,
  347. ParcPlace Systems, copyright 1988.
  348.  
  349. (2) Applications Programming in Smalltalk-80: How to Use
  350. Model-View-Controller (MVC) by Steve Burbeck, Softsmarts, Inc.,
  351. copyright 1987.
  352.  
  353. The first paper may still be in print.  Try info@parcplace.com.
  354.  
  355. The second paper is probably no longer available.  I think Softsmarts
  356. is the company that used to sell a version of Smalltalk for 80286
  357. machines but went out of business some years ago.  The phone number on
  358. the paper is listed as 415-327-8100 (Palo Alto, California).  You may
  359. try asking ParcPlace (or, less likely, Digitalk) if they have copies
  360. of Burbeck's paper.
  361.  
  362. --
  363. **********************************************************
  364. * Bruce Samuelson    Department of Linguistics     *
  365. * bruce@ling.uta.edu    University of Texas at Arlington *
  366. **********************************************************
  367.  
  368.  
  369. ---
  370.  
  371. 3.2)        Is there a Smalltalk bibliography?
  372.  
  373. Answer:
  374.  
  375.     There are many... here is one:
  376.  
  377. From: schultz@grebyn.com (Ronald Schultz)
  378. Newsgroups: comp.lang.smalltalk
  379. Subject: Smalltalk Relevant Texts
  380. Date: 10 Jan 92 16:08:05 GMT
  381. Organization: Grebyn Timesharing
  382.  
  383.  
  384. A list of Smalltalk-relevant texts.  Retrieved from the Digitalk
  385. forum on Compuserve.  If you know of any additional texts, please
  386. let me know.  Thanx.
  387.  
  388.  
  389. ==========================================================================
  390. Ron Schultz                                  
  391. Berard Software Engineering, Inc.            
  392. Columbus Ohio Office                           Headquarters
  393. 5634 Claire Court                              301 Lakeforest Drive
  394. Dublin, Ohio 43017                             Gaithersburg, Md. 20877
  395. Phone  (614) 798-0295                          (301) 417-9885  
  396. FAX    (614) 798-0296                          (301) 417-0021
  397. =========================================================================
  398.  
  399. Smalltalk 80 The Language, Adele Goldberg & David Robson
  400.         Addison-Wesley 1989             ISBN 0-201-13688-0
  401.  
  402. Smalltalk 80 The Interactive Programming Environment, Adele Goldberg
  403.         Addison Wesley 1984             ISBN 0-201-11372-4
  404.  
  405. Smalltalk 80 Bits of History, Words of Advice , Glenn Krasner
  406.         Addison Wesley 1984             ISBN 0-201-11669-3
  407.  
  408. Inside Smalltalk Volume I, Wilf Lalonde & John Pugh
  409.         Prentice Hall 1991              ISBN 0-13-468414-1
  410.  
  411. Inside Smalltalk Volume II, Wilf Lalonde & John Pugh
  412.         Prentice Hall 1991              ISBN 0-13-465964-3
  413.  
  414. Object-Oriented Graphics, P. Wisskirchen
  415.     Springer-Verlag 1990        ISBN 3-540-52859-8
  416.  
  417. Practical Smalltalk: Using Smalltalk/V, Dan Shafer and Dean A. Ritz.
  418.         Springer-Verlag                 ISBN 0-387-97394-X
  419.  
  420. Rapid Prototyping for Object Oriented Systems, Mark Mullen
  421.         Addison Wesley 1990             ISBN 0-201-55024-5
  422.  
  423. Object-Oriented Design, Peter Coad and Ed Yourdon
  424.     Yourdon Press 1991        ISBN 0-13-630070-7
  425.  
  426. Object Oriented Programming for Artificial Intelligence, Ernest Tello
  427.         Addison Wesley 1989             ISBN 0-201-09228-x
  428.  
  429. The Well Tempered Object, Stephen Travis Pope
  430.         MIT Press 1991                  ISBN 0-262-16126-5
  431.  
  432. RefTalk/Vwin, David Carl O'Neal
  433.         NuVista Press 1991              ISBN pending
  434.  
  435. Human-Computer Interface Design Guidelines, C. Marlin Brown
  436.         Ablex Publishing 1989           ISBN 0-89391-332-4
  437.  
  438. Designing Object-Oriented Software,
  439.                 Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener
  440.         Prentice-Hall 1990              ISBN 0-13-629825-7
  441.  
  442. Object Oriented Programming with Smalltalk/V, Dusko Savic
  443.         Ellis Horwood 1990              ISBN 0-13-040692-9
  444.  
  445. An Introduction to Object Oriented Programming & Smalltalk
  446.         Lewis Pinson & Richard Wiener
  447.         Addison Wesley 1988             ISBN 0-201-19127-x
  448.  
  449. SAA Common User Access Advanced Interface Design Guide
  450.         IBM 1989                        IBM Document # SC26-4582-0
  451.  
  452. IBM Red Books----(available from your IBM representative
  453.                   contact your local office of IBM and request
  454.                   the placing of an IBM Red Book Order.  If you
  455.                   are an IBM customer, the books are free.  If you
  456.                   are not an IBM customer, the books may have a nominal
  457.                   fee.)----
  458.  
  459. A Practical Introduction to Object Oriented Programming
  460.         IBM 1990                        IBM Document # GG24-3641
  461.  
  462. Object Oriented Design - A preliminary Approach
  463.         IBM 1990                        IBM Document # GG24-3647
  464.  
  465. Developing a CUA Workplace Application
  466.         IBM 1990                        IBM Document # GG24-3580-00
  467.  
  468. Managing the Development of Object Oriented Applications
  469.         IBM 1990                        IBM Document # GG24-3581-00
  470.  
  471. Object Oriented Analysis of the ITSO Common Scenario
  472.         IBM 1990                        IBM Document # GG24-3566
  473.  
  474. CUA Evaluation
  475.         IBM 1990                        IBM Document # GG24-3456
  476.  
  477. SAA CUA '91 Guide
  478.         IBM 1991                        IBM Document # SC34-4289
  479.  
  480. SAA CUA '91 Reference
  481.         IBM 1991                        IBM Document # SC34-4290
  482.  
  483. SAA - A Guide for Evaluating Applications
  484.         IBM 1991                        IBM Document # G320-9803
  485.  
  486.  
  487. ---
  488.  
  489. 3.3)+        What are the "blue book", "purple book", etc?
  490.  
  491. Answer:
  492.  
  493. Date: Wed, 11 Nov 92 12:52:39 PST
  494. From: khaw@parcplace.com (Mike Khaw)
  495.  
  496.  
  497. blue
  498.         Goldberg, Adele, and David Robson, _Smalltalk-80: The Language 
  499.         and Its Implementation_, Addison-Wesley, 1983. ISBN
  500.     0-201-11371-6. *Out of print* 
  501.          
  502. orange   
  503.         Goldberg, Adele, _Smalltalk-80: the Interactive Programming 
  504.         Environment_, Addison-Wesley, 1984. ISBN 0-201-11372-4. 
  505.          
  506. green    
  507.         Krasner, Glenn, ed., _Smalltalk-80: Bits of History, Words of 
  508.         Advice_, Addison-Wesley, 1983, ISBN 0-201-11669-3 
  509.          
  510. purple   
  511.         Goldberg, Adele, and David Robson, _Smalltalk-80: The Language_,
  512.         Addison-Wesley, 1989, ISBN 0-201-13688-0 
  513.          
  514. The books are actually cream or tan. The color referred to is the color 
  515. used as the background of the illustration on the front cover (as well 
  516. as for the Addison-Wesley logo on the spine). 
  517.  
  518. The purple book is an update/revision of the blue book, with the 
  519. section on the abstract bytecode machine omitted (because it was out 
  520. of date, according to Adele). 
  521. ----------
  522.  
  523. Mike
  524.  
  525.  
  526. ---
  527.  
  528. 4.0)+    [Programming issues]
  529.  
  530. ---
  531.  
  532. 4.1)+        What are some "classic Smalltalk bugs", both in the
  533.             system and programmer domains?
  534.  
  535. Answer:
  536.  
  537. Newsgroups: comp.lang.smalltalk
  538. From: johnson@m.cs.uiuc.edu (Ralph Johnson)
  539. Subject: catalog of classic bugs
  540. Summary: version 1 of the catalog of classic Smalltalk bugs
  541. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  542. Date: Wed, 12 Aug 1992 22:29:16 GMT
  543.  
  544. Classic Smalltalk Bugs
  545.  
  546. compiled by Ralph Johnson -- University of Illinois at Urbana-Champaign
  547.  
  548. Every programming system is prone to certain kinds of bugs.  A good
  549. programmer learns these bugs, and how to avoid them.  Smalltalk is
  550. no different.  Smalltalk eliminates lots of bugs that are common in
  551. other languages, such as bugs in linear search algorithms.  (Just use do:)
  552. However, it has its own set of classic bugs, which every new Smalltalk 
  553. programmer runs into.  
  554.  
  555. There are several reasons to collect classic bugs.  The first is that
  556. it will help experienced programmers test and debug programs, and can
  557. help us design better programs in the first place.  Second, if we
  558. teach these bugs up front then people should learn to be good
  559. programmers faster.  Third, perhaps we can redesign the system to
  560. eliminate some of these bugs, or we can write checking tools to
  561. spot them automatically.
  562.  
  563. Bug 1: Variable-sized classes
  564.  
  565. Set, Dictionary, and OrderedCollection are variable-sized classes
  566. that grow.  They grow by making a copy of themselves and "becoming"
  567. the copy.  If you add new instance variables to a subclass then
  568. you have to make sure that these instance variables get copied, too,
  569. or else you will mysteriously lose the values of the instance
  570. variables at random points in time.
  571.  
  572. Smalltalk-80 R4.0 (and probably some earlier versions) has a
  573. copyEmpty: method in Collection that you are supposed to override
  574. if you make a subclass of Collection that adds instance varaibles.
  575. The solution to this bug is to write a version of copyEmpty: for
  576. your class.
  577.  
  578. It has been suggested that it would be easy to write a tool that
  579. checked that every new subclass of Collection that added instance
  580. variables also defined a method for copyEmpty:.
  581.  
  582. Collection bugs
  583.  
  584. Bug 2: add: returns its argument
  585.  
  586. For every collection that grows, add: returns its argument,
  587. not the receiver, and people usually assume that it returns
  588. its receiver.  Thus, they write "(c add: x) add: y" when they should
  589. really write "c add: x; add: y" or else "c add: x. c add: y".
  590. Note that this is one of the good uses for "yourself", you can write
  591. (Set new 
  592.     add: x; 
  593.     add: y;
  594.     ...;
  595.     yourself) 
  596. to make sure that you have the new Set.
  597.  
  598. Note that there are good reasons why add: returns its arguments,
  599. and even if there weren't, it is a very, very bad mistake to
  600. implement add: so that it returns the receiver, and so confuse
  601. every other Smalltalk programmer on the planet.
  602. Making add: return its argument often keeps you from resorting
  603. to temps, because you can create the argument to add: on the
  604. fly, and then do other things with it after the add:.  If you
  605. want to access the collection, you can do it with yourself or
  606. cascaded messages, as described above.
  607.  
  608. Bug 3: changing collection while iterating over it
  609.  
  610. You should never, never, never iterate over a collection which
  611. the iteration loop somehow modifies. Elements of the collection
  612. will be moved during the iteration, and elements might be missed
  613. or handled twice.  Instead, make a copy of the collection you
  614. are iterating over, i.e.
  615.    aCollection copy do: [:each | aCollection remove: each]
  616. is a good program, but if you leave out the copy then it isn't.
  617.  
  618. Mario Wolczko suggested a solution that catches this problem the
  619. instance it occurs (at some performance penalty of course).  The
  620. solution is to change the collection classes.  Each iteration method
  621. enters that collection into a set of collections being iterated over
  622. (IteratedCollections), executes the block, then removes the collection
  623. from the set.  Collections are usually (only?) modified using at:put:
  624. or basicAt:put:, so these are overriden to check that the collection
  625. is not in IteratedCollections.  If it is, an error is signalled.  You
  626. can either use this technique all the time, or you can just install
  627. these classes when you are testing and debugging your program.  These
  628. changes are packaged in a file Iterator-check.st that is available on
  629. the Manchester and Illinois servers.  On the Illinois server, it is
  630. in /pub/MANCHESTER/manchester/4.0/Iterator-check.st.
  631.  
  632. Bug 4: modifying copies of collections
  633.  
  634. It is common for an object to have an accessing method that returns a
  635. collection of objects that you can modify.  However, sometimes
  636. an object will return a copy of this collection to keep you from
  637. modifying it.  Instead, you are probably supposed to use messages
  638. that will change the collection for you.  The problem is that this
  639. is often poorly documented, and a person who likes to modify collections
  640. directly will run into problems.  See  "ScheduledControllers
  641. scheduledControllers" for an example.
  642.  
  643. The solution is to either provide better documentation, to claim
  644. that nobody is allowed to modify copies of collections returned
  645. from other objects, or to have objects that don't want their
  646. collections modified to return immutable versions of the collections
  647. that will give an error if you try to modify them.
  648.  
  649. Bug 5: Missing ^
  650.  
  651. It is very easy to leave off a return caret on an expression.
  652. If there is no return at the end of a method, Smalltalk returns
  653. the receiver of the method.  It only takes one missing return
  654. to mess up a long chain of method invocations.
  655.  
  656. Bug 6: Class instance creation methods
  657.  
  658. Writing a correct instance create method is apparently non-trivial.
  659. The correct way to do it is to have something like
  660. new
  661.   ^super new init
  662. where you redefine init in each class to initialize that class's
  663. instance variables.  In turn, init is defined as a class method
  664. init
  665.   super init "to initialize inherited instance variables"
  666.   "initialize variables that I define"
  667.  
  668. There are lots of ways to do this wrong.  Perhaps the most common
  669. is to forget the return, i.e. to write
  670.    super new init
  671. The result is that you have the class where you want the instance of
  672. the class.  This is a special case of bug #?.
  673.  
  674. Another error is to make an infinite loop by writing
  675.   ^self new init
  676.  
  677. If Smalltalk doesn't respond when you think it should, press ^C to
  678. get the debugger.  If the debugger shows a stack of "new" messages
  679. then you know you made this mistake.
  680.  
  681. Finally, you should only define "new" once for each class hierarchy
  682. and let subclasses inherit the method.  If you redefine it in each
  683. class then you will reinitialize the new object many times, wasting
  684. time and perhaps memory.
  685.  
  686. One way to keep this from happening is to make the "new" method in
  687. Object send init, and have the "init" method in Object do nothing.
  688. Of course, sometimes the version of init that you define has arguments,
  689. and this wouldn't help those cases.  It is probably better to rely
  690. on education to eliminate this kind of error.
  691.  
  692. Bug 7: Recompiling bugs in Smalltalk/V
  693.  
  694. It is easy to have references to obsolete objects in Smalltalk/V
  695. if you change code without cleaning things up carefully. For example,
  696. the associations whose keys are the referenced names in the Pool 
  697. Dictionary are stored in the CompiledMethods at compile time. If you 
  698. create a new version of the Pool Dictionary and install it by simple
  699. assignment then the compiled methods still refer to the old associations.
  700.  
  701. If you substitute a new instance of Dictionary or replace, rather than
  702. update an association in a pool dictionary, you have to recompile all
  703. methods using variables scoped to that Pool.
  704.  
  705. This is is also annoying when using ENVY, where the methods are under
  706. strict control. Perhaps Pool Dictionaries should be be first-class
  707. versioned pre-requisites of Classes, just like the class definition.
  708.  
  709. BTW we are using/VPM 1.4 with ENVY 1.3
  710.  
  711. 1. If you prune & graft a subtree of your class structure you have to
  712. make sure that all referencing methods are recompiled. Otherwise you
  713. will run (or your customer, because this is only detected at run time)
  714. into an Deleted class error message.
  715. Thomas Muhr posted a "Bite" a while ago to handle this problem for
  716. Smalltalk/V 286.
  717.  
  718. Bug 8: Opening windows
  719.  
  720. Neither Smalltalk-80 nor Smalltalk-V return to the sender when a
  721. new window is opened in a standard fashion. Thus, any code after
  722. a message to open a window will never be executed.  This is the
  723. cause of much frustration.  For example, if you try to open two
  724. windows at once, i.e.
  725.  
  726. TextPane new open.
  727. TextPane new open
  728.  
  729. is Smalltalk-V and
  730.  
  731. aScheduledWindow1 open.
  732. aScheduledWindow2 open
  733.  
  734. in Smalltalk-80, then you will get only one open window,
  735. and one forgotten piece of code.
  736.  
  737. I don't know the fix for Smalltalk-V.  The fix for Smalltalk-80 is
  738. to use the openNoTerminate method to open the window, which does
  739. not transfer control to it.  A useful trick is to store the new
  740. window in a global variable so you can test it.  In earlier
  741. versions of Smalltalk-80, open would obliterate the current
  742. process, not just never return to it.  In Version 4.1 that
  743. never happens.
  744.  
  745. Bug 9: blocks
  746.  
  747. Blocks are very powerful, and it isn't hard for programmers to get
  748. into trouble trying to be too tricky.  To compound problems, the
  749. two versions of Smalltalk have slightly different semantics for
  750. blocks, and one of them often leads to problems.
  751.  
  752. Originally blocks did not have truly local variables.  The block
  753. parameters were really local variables in the enclosing method.
  754. Thus,
  755.  
  756. | x y |
  757.   x := 0.
  758.   (1 to: 100) do: [:z | x := x + z]
  759.  
  760. actually had three temporaries, x, y, and z.  This leads to bugs
  761. like the following
  762.  
  763. someMethod
  764.  
  765.  | a b  |
  766.  a := #(4 3 2 1).
  767.  b := SortedCollection sortBlock: [:a :b | a someOperation: b].
  768.  b addAll: a.
  769.  Transcript show: a.
  770.  
  771. When elements are added to b, the sortBlock is used to tell where
  772. to put them, but this will change a and b.  addAll: is OK, but
  773. the "a" that gets displayed on the transcript will be an integer,
  774. not an array.
  775.  
  776. Early versions of Smalltalk-80 (2.4 and before?) implemented blocks
  777. like this, and Smalltalk/V still does.  However, in current PPS
  778. implementations, blocks are close to being closures. You can declare
  779. variables local to a block, and the names of the block parameters are
  780. local to the block. Most people agree that this is a much better
  781. definition of blocks than the original one.  Nevertheless, people
  782. planning to use Smalltalk/V should realise that it has a different
  783. semantics for blocks.
  784.  
  785. This difference can lead to some amusing problems.  For example, here
  786. is some code written by someone who had obviously learned Scheme.
  787.  
  788. | anotherArray aBlockArray |
  789.  
  790. aBlockArray := Array new: 4.
  791. anotherArray := #(1 2 4 8).
  792.  
  793. 1 to: 4 do: [ :anIndex |
  794.  aBlockArray at: anIndex put: [ (anotherArray at: anIndex) * 2 ]].
  795.  
  796.  
  797. The programmer expected that each block would be stored in the array
  798. along with its own value of anIndex.  If anIndex were just a local
  799. variable of the method then this will not work.  It assumes that 
  800. each execution of the block gets its own version of anIndex, and
  801. Smalltalk/V and old Smalltalk-80 actually make each execution share
  802. the same version.
  803.  
  804. So, if you are using Smalltalk/V then be careful not to reuse the
  805. names of arguments of blocks unless you know that the blocks are
  806. not going to have their lives overlap.  Thus,
  807.  
  808.   aCollect do: [:i | ...].
  809.   bCollect do: [:i | ...].
  810.  
  811. is probably OK because do: does not store its argument, so the
  812. blocks will be garbage by the time the method is finished.
  813. However, if the first block were stored in a variable somewhere
  814. and evaluated during the execution of the second block then
  815. problems would probably occur.
  816.  
  817. Bug 10: Smalltalk/V class library
  818. Thomas Muhr makes these comments about bugs in the Smalltalk/V
  819. class library that you should know if you want to keep your
  820. programs fast and correct.
  821.  
  822. 2. Never use symbols to label objects if you are dealing with many
  823. objects. This will slow down your system to an almost dead halt. Use
  824. strings instead.
  825. 3. Never use Sets when you can otherwise assure the uniqueness. Look
  826. at the implementation of "add:" for Sets and you'll know what I mean:
  827. on every "add:" the new element is compared to all others resulting
  828. into a nonlinear time for adding to Sets.
  829. 4. Do not think that if you "collect:" something from a
  830. SortedCollection, that your result will be sorted as the origin,
  831. unless you use the default sortBlock. This is one of the bugs provided
  832. by the language vendor
  833.  
  834.  
  835.  
  836. Many thanks to the many people who contributed bugs or solutions to bugs
  837. to the list.  These include
  838.  
  839.  muhr@opal.cs.tu-berlin.de (Thomas Muhr)
  840.  steinman@is.morgan.com (Jan Steinman)
  841.  knight@mrco.carleton.ca (Alan Knight)
  842.  mario@cs.man.ac.uk (Mario Wolczko)
  843.  peterg@netcom.com (Peter Goodall)
  844.  Aad Nales <nales@cs.few.eur.nl>
  845.  scrl@otter.hpl.hp.com (Simon Lewis)
  846.  msmith@volcano.ma30.bull.com (Mike Smith)
  847.  dai@mrco.carleton.ca (Naci Dai)
  848.  dcr0@speedy.enet.dec.com (Dave Robbins)
  849.  randy@tigercat.den.mmc.com (Randy Stafford)
  850.  Hubert.Baumeister@mpi-sb.mpg.de (Hubert Baumeister)
  851.  eliot@dcs.qmw.ac.uk (Eliot Miranda)
  852.  dmm@aristotle.ils.nwu.edu (donald)
  853.  amir@is.morgan.com (Amir Bakhtiar)
  854.  Kurt Piersol <Piersol@Apple.com>
  855.  sullivan@ticipa.ti.com (Michael Sullivan)
  856.  terry@zoe.network23.com (Terry)
  857.  brent@uwovax.uwo.ca (Brent Sterner)
  858.  frerk@informatik.uni-kl.de
  859.  nicted@toz.buffalo.ny.us (Nicole Tedesco)
  860.  riks@ogicse.ogi.edu (Rik Fischer Smoody)
  861.  marten@feki.toppoint.de (Marten Feldtmann) 
  862.  
  863. Comments and additions are welcome.  Please post to comp.lang.smalltalk
  864. or e-mail to johnson@cs.uiuc.edu.
  865.  
  866. ---
  867.  
  868. End of Smalltalk FAQ
  869.  
  870.